System timers are used to drive time-sensitive operating processes such as task switches and system time keeping. A system timer is generally a hardware device that, once started, does not require interfacing with an operating system to keep its time accurate since it receives its timing signal from the system clock and automatically creates and sends out interrupts at time slices in multiples of the clock rate.
As shown in FIG. 1, hardware timers typically consist of a load register (6), a count-down register (7), and a controller (8). Operating process generated values (22A) are loaded into the load register. Depending on instructions of the controller, the value in the load register is transferred to the count-down register on a reference clock signal tick (9). The count-down register decrements its value on each successive clock tick, until a programmed value is reached (typically “0”), at which point the clock signal is passed through the timer as a timer interrupt (10), which passes to the operating system.
However, in many circumstances, timers are created by system software. These are referred to as dynamic timers. With dynamic timers, timer lists with calculated time settings are created and maintained by the operating system for each timer. Entries in the timer lists are associated with various devices and processes, controlled by the CPU, which often require a precisely timed interrupt for their operation. The precision of such an interrupt may involve a fraction of a system tick time slice. A system doze mode wake-up alarm is a simple example of a process which requires the assistance of timer-scheduled interrupts.
Timer list entries are based on a calculated number of whole and fractional system ticks (the delay) required between the system tick occurring as the timer set signal is received by the timer set-up routine and the point of time in the future that the interrupt must fire. Because the timers are created and maintained by software, dynamic timers require that a system's CPU be up and running to serve the timer's set-up and interrupt routines.
During normal operation, after a dynamic timer fires an interrupt, the CPU must walk through its timer lists and reconfigure any remaining timer settings, particularly when a timer has expired and fired its interrupt part-way through a system tick interval. This places a heavy demand on the operating system, especially since resource-intensive fractional mathematics are required to perform any partial time slice reset calculations as a result of such an interrupt. Since these recalculations must be done for each dynamic timer, the process of maintaining dynamic timers collectively consumes a large amount of valuable CPU resources.
As mentioned above, all interrupt setup times on a dynamic timer list are recalculated after each and every interrupt fires. The recalculations are based on (and thus reset from) the timing of the most recent interrupt. The actual system time required to make the reconfiguring calculations may vary depending on the number of entries in the timer list as well as on the number of other system tasks running simultaneously. Therefore, inaccuracies may occur as a result of repeated recalculations of a number of timers. Over time these inaccuracies accumulate, causing timer-related system problems.
Further, when devices are dependent on a dynamic timer system, the system CPU must remain up and running to serve the timer creation, time calculation and timer interrupt routines. On many portable devices, it would be desirable to put the CPU to “sleep”, having it shut down completely to conserve battery power between operating events, especially if the device is designed for relatively long periods of time with no use. Since placing the CPU to sleep would require that the dynamic timer programs be shut down, it is not possible to shut down the CPU and conserve power where operating systems utilize dynamic timers to control system sleep modes.
These three deficiencies in legacy operating systems (utilizing system resources for factional mathematic calculations, creating inaccuracies as a result of repeated calculations and an inability to shut down the CPU to save battery power during sleep mode) create a need for an improvement to the current state of the art.